1. The Field of the Invention
The present invention relates to computer system authentication, and more specifically, to challenges for determining the identity of a computer system and challenges for potentially reducing the impact of denial-of-service attacks.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks performed at a computer system (e.g., accessing electronic mail and web browsing) include electronic communication with one or more other computer systems via a computer network (e.g., the Internet).
Often, electronic communication on a computer network includes a client computer system (hereinafter referred to as a “client”) requesting access to a service (e.g., electronic mail or a web page) at a server computer system (hereinafter referred to as a “server”). Before granting the client access to the service, the server may issue a challenge to the client requiring the client to prove it's identity to the server. A challenge may be a relatively simple challenge, such as, for example, challenging a user at the client to enter a user-name and password. On the other hand, a challenge may be more complex, such as, for example, challenging the client to correctly perform a complex handshake sequence.
Unfortunately, existing challenge mechanisms often utilize specialized protocols to issue challenges and receive responses to challenges. Some of these specialized protocols, such as, for example, the Session Initiation Protocol (“SIP”), prescribe both the types of challenges that are used and the protocols used to implement the challenges. Other of these specialized protocols, such as, for example, the Secure Sockets Layer (“SSL”) handshake sequence and Secure and Protected Negotiation (“SPNEGO”) allow the protocols used to implement challenges to be varied.
However, while the algorithms used to implement challenges can be varied, the types of challenges typically cannot. For example, the SSL handshake sequence requires particular portions of data exchanged between the client and server to be signed. While the algorithms used to sign the data can be varied, the requirement that the particular portions of data be signed cannot be varied. Further, the different algorithms used to sign data are hard coded into SSL. Thus, an SSL handshake sequence is typically limited to these hard coded algorithms.
This makes it difficult to extend the SSL handshake sequence (or other typical challenge protocols) to support additional types of challenges and support additional algorithms for implementing challenges. Further, as challenges can be used in a large and diverse number of different computing environments, there is little chance that every possible type of challenge and algorithm could be implemented by a single handshake protocol. Altering a well-documented or standardized protocol, such as, for example, the SSL handshake protocol, can also lead to incompatibilities between computer systems.
Thus, an application designer may be constrained to using existing types of challenges even if some other type of challenge would be more advantageous for a particular application. In any event, applications (in part due to the configuration of protocol stacks) often lack the ability to alter functionality in lower layers of a protocol stack (e.g., the transport layer) where handshake protocols typically operate. Thus, even if an application desired the performance of a particular challenge, the application would have limited, if any, mechanisms to alter the functionality of a handshake protocol to implement the particular challenge.
Additionally, some protocols used to issue challenges are limited in the type of communications they support. For example, the SSL handshake is a state-based protocol that functions only when Transmission Control Protocol (“TCP”) is used as a transport. Thus, applications that use stateless protocols, such as, for example, Universal Datagram Protocol (“UDP”), as a transport cannot issue or respond to SSL challenges. This is unfortunate as many applications use stateless protocols due to the low overhead associated with these protocols.
Further, the use of state-based protocols can increase the detrimental effects of attacks that flood a computer system with useless requests (commonly referred to as “denial of service” attacks). When a request is received, state information is created and maintained for the request. Typically, state information continues to be maintained for some amount of time after the request is received, even if no additional data for the request is received. For example, a computer system may maintain state information for a request during the period of time it waits for a response to an issued challenge. However, the initiator of the denial service attack is typically not interested in accessing the computer system and typically does not respond to the issued challenges. Thus, each request in a denial of service attack can consume computer system resources (e.g., system memory) even though none of the requests result in access to the computer system.
Therefore systems, methods, computer program products, and data structures for selecting a challenge from among different types of challenges would be advantageous. Systems, methods, computer program products, and data structures for issuing and responding to challenges in a stateless manner would also be advantageous.